The Liberty Alliance Project defines the Identity Web Services Framework (ID-WSF) upon the foundation of Identity Federation Framework (ID-FF) to provide a framework for identity-based web services in a federated network identity environment. A Liberty Identity Service Instance Specification (ID-SIS) is also defined to allow user's attribute information to be shared among “federated” service providers (SP).
Using the single sign-on functionality provided by an implementation of Liberty ID-FF, when a user's browser accesses a SP, the SP redirects the user's browser to a to a particular one of the providers that is designated as the user's “identity provider” (“IDP”). The IDP can authenticate the user and redirect the user's browser back to the SP that the user's browser originally accessed. As a result, the other SPs do not need to authenticate the user prior to allowing the user to access those other SPs' services. The user is spared the burden of separately providing authentication information (e.g., username and password) to each separate SP, even if the user's authentication information differs for each SP.
An implementation of Liberty ID-WSF and ID-SIS can also allow one SP to obtain a user's attribute information from another service provider. In such a scenario, the SP that seeks to obtain the attribute information is called the “web service consumer” (“WSC”) and the service provider that provides the attribute information to the WSC is called the “web service provider” (“WSP”). For example, if the WSC needs a credit card number, a social security number, or any other attribute information for a user, the WSC can query the user's WSP and obtain the desired attribute information without asking the user to manually enter the information, which the user has already provided to the user's WSP.
Before a WSC can obtain a user's attribute information from the user's WSP, the WSC needs to have access information that tells the WSC how to access the user's WSP. This access information may comprise, for example, a Simple Object Access Protocol (SOAP) endpoint of the WSP. Using the WSP's endpoint, the WSC can direct queries to the WSP.
In order to obtain such access information for the WSP, the WSC may query a directory service provider (“DSP”). In many cases, the DSP is hosted on the same computer as the IDP. The DSP typically has access to a data structure that contains associations between users and the access information (Resource Offering) for those users' WSPs (each separate user may be associated with one or more different WSPs). Thus, the WSC may query the DSP, indicating, in the query, identifying information that is associated with a particular user. Receiving the query, the DSP may determine, from the data structure, the access information for WSP instances that are associated with the particular user. The DSP may respond to the WSC's query with the particular WSP's access information. Receiving the response, the WSC may then query the particular WSP to request the particular user's attribute information as described above.
The data structure discussed above needs to contain an association between a user and that user's WSPs' access information before the DSP can provide that access information to a WSC. Often, thousands of users that belong to a single business organization should be associated with the same WSP access information. For example, a company might outsource, to the same benefits provider, all of the benefits for all of the company's employees. In such a scenario, associations would need to be established between each employee and the benefits provider, which functions as a WSP.
One approach to establishing these associations uses Liberty Discovery Service's “Modify” operation. Using the modify operation, an association between a user and a WSP's access information can be inserted into the data structure discussed above. However, the Modify operation is designed to insert only one user association into the data structure at a time. Thus, in the case of millions of users, the Modify operation would need to be invoked millions of times.
Additionally, the discussion above assumes that the WSC is enabled to use an implementation of Liberty ID-FF version 1.2. According to Liberty ID-FF version 1.2, an IDP provides “bootstrap” information to a WSC when the IDP redirects the user's browser to the WSC, as described above. The bootstrap information indicates how to access the user's DSP.
However, some WSCs are not enabled to use Liberty ID-FF version 1.2. Some WSCs are enabled to use Liberty ID-FF version 1.1. Some WSCs are not enabled to use Liberty ID-FF at all. WSCs that are not enabled to use Liberty ID-FF version 1.2 do not receive the bootstrap information from a user's IDP as described above. Without the bootstrap information, such non-enabled WSCs are unable to query a user's WSP in order to discover the user's WSP's access information.